Run-time loading of compiled code into a running program is supported within the Unix operating system (via the DLOPEN command) and within the Windows operating system (via dynamic linked libraries (DLLs)).
In general, a dynamic library interface allows a calling program to load and call function ‘Y’ from a library file ‘X’. The library file is opened either automatically by the program or via explicit library calls. Plug-ins use fixed data structures (for parameters) and database schema changes (to introduce new sets of data to be processed rather than simply populating data in schema) to support these calls. But plug-ins have no “data type” safety at either compile or run time on the data interchanged. Therefore, data can be freely misinterpreted. Some shared library implementations may support type checking by compiling stubs (a stub is a small program routine that substitutes for a longer program, possibly to be loaded later or that is located remotely) with the linked module. Here, however, the calling code needs to be recompiled to use a new function interface. This sometimes results in “bringing down” servers in a production environment for an indeterminate length of time.
Most interpreted script environments can support run-time loading of script code. Hybrid environments are also available where a script engine can load script code to interpret and execute, and also load compiled code registered as functions that can be invoked explicitly from the script language (e.g., the LUA script engine described at http://wwwluaorg).
In a conventional system, few safeguards can be provided to ensure that only code modules with the same application inputs and outputs can be assembled together. Such checking cannot, normally, be undertaken at run-time as new code modules and new application types are defined. Known partial solutions, such as JAVA, include the use of a strongly-typed object-oriented language with compile time checking. However, these solutions do not operate with a) simple procedural code development tools based on simple types; b) environments with different plug-in language, or c) new type definition, validation and invocation at runtime.
Finally, plug-ins also do not provide any integrated caching support.